Advanced topic 6, 2012
Paper: On the Impact of Security Protocols on the Performance of SNMP The content of this wiki page was adapted from the paper above. All credit goes to original authors. Background: Know: SNMP security, Recognize: SNMP and UDP, SNMP fragmentation The paper J. Schonwalder and V. Marinov, "On the Impact of Security Protocols on the Performance of SNMP", ;presented at IEEE Transactions on Network and Service Management, 2011, pp.52-64. describes how SSH, TLS, and DTLS can be used to take advantage of already deployed key management infrastructures and hence reduce the operating expenses associated with securing SNMP. The performance between the various options to secure SNMP are discussed before concluding guidelines for choosing solutions. SNMP Architecture The SNMP architecture defined in Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. and Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. allows for the addition of future protocol extensions such as additional security models or transports. SNMP Engine The SNMP engine consists of a dispatcher and several subsystems. Each subsystem can contain multiple models implementing the services. Abstract Service Interfaces (ASIs) are used between the communicating subsystems. * Dispatcher ::The dispatcher organises the data flow coming from transports, going up to applications and back to the network through the engine. * Message Processing subsystem ::Different versions of SNMP messages, e.g., SNMPv1, SNMPv2c, and SNMPv3, are to be dispatched to their own message processing models. * Security subsystem ::The SNMPv3 message processing model uses the User-based Security Model (USM) Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. while the SNMPv1 and SNMPv2c message processing models use the Community-based Security Model (CSM) Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. to provide security services on a per SNMP message basis, so called message-based security. To address the limitations of the original message-based architecture design, the Transport Security Model (TSM) Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. was introduced to interact with session-based secure transports through a shared cache. * Access Control subsystem ::The View-based Access Control Model (VACM) is available in SNMPv3 to provide the access control mechanism. * Transport subsystem ::The transport subsystem, which was not part of the original SNMP architecture, has been defined by the Integrated Security Model for SNMP (ISMS) working group of the Internet Engineering Task Force (IETF) to allow multiple transport protocols to be "plugged into" an SNMP engine. The SSH Transport Model (SSHTM) Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. and the (D)TLS Transport Model (TLSTM) Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011. provide security services on a per session basis, so called session-based security. Message-based Security * Community-based Security Model ::The CSM used by SNMPv1 and SNMPv2c are not secure as the community strings are trasmitted in plain text across the network. * User-based Security Model ::The USM used by SNMPv3 provides three levels of security: :*noAuthNoPriv (nn): no authentication, no encryption :*authNoPriv (an): message authentication, message integrity, timeliness checking, but no encryption :*authPriv (ap): security services plus encryption of the payload of SNMP messages :The time-sequence diagram below shows IP packets exchanged when executing a SNMP GET operation of SNMPv2c and SNMPv3/USM over UDP and TCP, including the typical TCP connection establishment and teardown exchange. The GET/REPORT exchange is usually used for the engine discovery and the USM clock synchronisation. Session-based Security * Transport Security Model ::The Transport Security Model (TSM) implements the ASIs of the security subsystem to provide the security information to the rest of the SNMP engine via the shared cache. From a performance perspective, the TSM processing costs are negligible since it only passes existing information while the actual translation of transport-specific and SNMP-specific security parameters happens within a secure transport model. * SSH Transport Model ::The Secure Shell (SSH) protocol Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. provides secure network services over an insecure network. It is composed of three layers: :*The Transport layer uses public-key cryptography to authenticate the server, handles key exchanges, and setups a secure connection over a reliable data stream. :*The User Authentication layer supports a number of methods to authenticate the client. :*The Connection layer allows a single connection to host multiple channels simultaneously. * TLS Transport Model (for TLS) ::The Transport Layer Security (TLS) protocol Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. is widely used to secure application layer protocols. It is composed of two layers: :*The Record layer can be implemented on top of transport layer protocols to provide security services by encapsulating the application layer protocols. :*The Handshake layer allows the server and client to authenticate each other and negotiate various parameters to establish a secure connection. ::The TLS session resumption mechanism uses the security parameters cached during the previous session to bypass expensive key exchange procedure when resuming the session, consequently saving the server load and more importantly round trip time. Note that while TLS supports multiple authentication methods, TLSTM requires the use of X.509 certificates. * TLS Transport Model (for DTLS) ::The Datagram Transport Layer Security (DTLS) protocol Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. is based on TLS but provides secure communication over unreliable datagram transports. It is composed of two layers similar to TLS: :*The DTLS Record layer adds an explicit sequence number to allow the recipient to verify the TLS MAC for Anti-replay and message reordering protections. :*The DTLS Handshake layer assigns a sequence number to each handshake message, as TLS messages are required to be transmitted and received in a defined order. Each handshake message may be fragmented over several records if the given datagram is small. The stateless cookie exchange is added to the initial handshake to prevent denial of service attacks. :The time-sequence diagram shows SSHTM has the longest process among all models since it needs three phases to establish the connection. In the scenario, the authentication requires several trips to discover available authentication mechanisms and try them in sequence. As for the TLSTM with and without session resumption, the diagram shows minor differences. However there is a significant difference in terms of CPU cycles needed and the resulting latency, as will be shown in the later measurement. DTLSTM requires less packets than TLSTM due to its transport being UDP. Performance Evaluation The performance reports were based on the prototype implementation of SNMP over SSH/TLS/DTLS developed as an extension of the Net-SNMP SNMP implementation. The libssh library was used for the SSH protocol, and the OpenSSL library was used for the TLS/DTLS protocols. | |} Session Establishment :The table below shows the latency measurement of performing SNMP GET operations on the scalar sysDescr.0 using different versions of SNMP with agents on a fast machine and a slow machine. :# TCP has connection setup and teardown overhead resulting in a larger number of round trips and hence the higher latency. Otherwise the performance of SNMPv1 and SNMPv2c is similar. :# The USM discovery exchange makes SNMPv3/USM/nn more expensive than SNMPv1/SNMPv2c. However the overhead for enabling the authentication and privacy in USM is relatively small. :# The session establishment involves cryptographic operations, resulting in significant delays, especially noticeable on the slow machine. SSH has higher delay and bandwidth usage due to more messages required than TLS/DTLS. :# With session resumption, TLSsr is close to USM in terms of bandwidth consumed and packets exchanged while the session key verification overhead contributes the higher latency. Latency without Packet Loss :In this and the following sections, the performance is measured by walking the ifTable. : Bandwidth Usage : Latency with Packet Loss : Impact of Bulk Retrieval : Key Findings *The session resumption feature of TLS reduces the session reestablishment costs significantly. The resumption mechanism for SSH has yet to be standardised. *The difference between USM, SSH, TLS and DTLS in terms of latency is small after the session is established. *The non-adaptive SNMP retransmission algorithm is outperformed by TCP algorithms in packet loss networks. *The usage of GetBulk dramatically reduces the number of requests sent over the network, resulting in much better overall performance. Guidelines for Choosing Suitable Solutions SNMPv3/TSM/SSH :SSHTM :*It integrates well with CLI management interfaces. :*It allows for integration with AAA servers using RADIUS Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. or Diameter Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.. :*The SSH user identity can be easily mapped to securityName for VACM. :*SSH is efficient in encoding messages. :*'con:' SSH incurs large session establishment overhead and is lack of session resumption mechanisms. :TCP :*TCP supports large SNMP messages better than UDP does. :*TCP retransmission algorithms work well in networks with low loss rates. :*'con:' TCP retransmission algorithms might not be problematic if the packet loss rate is high enough to cause retransmission timeouts, which may eventually leand to the throughput degradation. : SNMPv3/TSM/TLS :TLSTM :*The session resumption feature reduces the load. :*TLS has less session startup overhead than SSH. :*'con:' TLS is less efficient in encoding messages than SSH. :*'con:' The derivation of securityName is complicated. :*'con:' It is lack of good AAA integration. :*'con:' A X.509 public key infrastructure must be in place. :TCP :*SNMPv3/TSM/TLS shares the same pros and cons of using TCP as mentioned earlier in SNMPv3/TSM/SSH. : SNMPv3/TSM/DTLS :(D)TLSTM :*It shares most of the pros and cons of TLSTM. :UDP :*DTLS has smaller framing overhead than TLS since there is no TCP header. :*Applications have control over retransmissions, although application retransmission timers are to be coordinated with DTLS retransmission timers. : SNMPv3/USM/UDP :USM :*A separate key management infrastructure ensures the availability of security functions regardless of the presence of other infrastructures. :*'con:' Deploying a new key management infrastructure is expensive. :*'con:' It is lack of AAA integration. :UDP :*It works efficiently if SNMP interactions are sporadic. :*Applications can have full control over retransmissions. :*'con:' It would suffer from IP fragmentation for bulk data transfers. : See also *Advanced Topics 2012 *Session resumption for the secure shell protocol References